Somewhere in your last renewal packet from a PLC, HMI, or historian vendor, there’s probably a new document you haven’t seen before. It’s not a datasheet, not a EULA, and not a CVE bulletin. It’s an attestation letter — a formal statement that the vendor’s product development process aligns with CISA’s Secure by Design principles. If you filed it in the same folder as the warranty terms and moved on, you’re not alone. Most plant IT and controls teams are getting these letters with zero guidance on what they’re actually for.
That’s the gap this piece is trying to close. CISA’s Secure by Design pledge has been around for a while as a voluntary commitment signed by software and ICS vendors. What’s changing heading into 2026 is that the pledge is starting to generate artifacts — actual attestation documents tied to specific products, arriving at specific renewal dates, with specific (if vague) claims about memory-safe languages, default credentials, vulnerability disclosure programs, and secure defaults. That’s a meaningful shift. A pledge is a press release. An attestation letter attached to a contract renewal is a document you can hold a vendor to.
What an attestation letter actually promises — and what it doesn’t
Read one of these letters closely and you’ll notice they cluster around a handful of claims: elimination of default passwords, support for multi-factor authentication on remote access paths, use of memory-safe languages in new development, published coordinated vulnerability disclosure policies, and generation of a software bill of materials (SBOM) for the product line. These map fairly directly to the secure-by-design principles CISA has been pushing since the pledge launched — reduce entire classes of vulnerability rather than patch them one at a time.
What the letters typically do not promise is a timeline. They tell you the vendor is committed to a direction, not when your specific controller firmware or SCADA package will actually reflect that direction. They also almost never say anything about legacy product lines still in the field — the attestation is usually scoped to current and future releases, which means the RTU you installed years ago is not covered by anything in that letter, no matter how reassuring it sounds.
That distinction — forward-looking commitment versus backward-looking coverage — is the single most important thing to extract from these documents. If you skim past it, you’ll walk away thinking your fleet is more current than it is.
Mapping attestations to your SL-A targets
If your OT security program is built around IEC 62443 zone and conduit models, you already have security level target (SL-T) assignments for the zones your assets sit in, and presumably some sense of the security level capability (SL-C) your existing equipment can actually deliver. This is where attestation letters earn their keep: they let you cross-reference a vendor’s stated direction against the specific SL-C gaps you’ve already documented.
Concretely, that means pulling out your existing gap assessments — the ones that probably say things like “authentication mechanism does not support role-based access consistent with SL-T 2” — and checking each gap against the attestation. Does the letter’s memory-safe language commitment touch the component with the buffer-overflow history? Does the default-credential elimination claim cover the HMI runtime you flagged in your last risk assessment, or only a newer product family you haven’t purchased? Most of the time you’ll find partial overlap. That partial overlap is exactly the leverage you want, because now you’re not asking the vendor for security improvements in the abstract — you’re asking them to close a specific, already-documented SL-C gap that their own attestation says they’re working toward anyway.
Building the gap map
- List the attestation claims verbatim — default credentials, MFA support, SBOM availability, memory-safe rewrite scope, vulnerability disclosure SLA if one is stated.
- Cross-reference against your asset inventory by product line and firmware/software version, not just by vendor name. Attestations are usually product-specific, and vendors sell a lot of product lines.
- Flag anything attested but unscheduled. A claim with no target release or date is not yet actionable — it’s a talking point for your next contract conversation.
- Flag anything your fleet needs that isn’t attested at all. This is often the most useful output: a documented, vendor-acknowledged silence on a capability you actually need.
What changes in your patch cadence — and what doesn’t
Here’s the part that’s easy to get wrong: secure-by-design attestations are not a patch cycle accelerant on their own. They’re a design philosophy commitment, and design changes ship on product release cycles, not patch Tuesdays. If anything, a serious secure-by-design push can slow the delivery of incremental patches in the short term while a vendor reworks build pipelines, adopts memory-safe toolchains, or restructures how credentials are handled — that’s real engineering work with real regression risk, and a vendor doing it properly should be testing thoroughly before it ships into an environment running continuous production.
What should change is your evaluation of vendor-supplied patches once they arrive. A patch from a vendor that has attested to eliminating default credentials and adopting memory-safe development practices carries a different risk profile than the same category of patch from a vendor with no such commitment — you’d expect fewer patches addressing entire vulnerability classes that shouldn’t have existed in the first place, and more patches addressing genuinely novel issues. Track that. If a vendor’s post-attestation patch stream still reads like pre-attestation patch streams — same categories of buffer overflows, same hardcoded credential findings — that’s a signal worth raising at renewal, not a reason to panic-patch faster.
What to actually demand in the next contract cycle
This is where most plant IT teams leave value on the table. The attestation letter shows up, gets acknowledged, and the renewal proceeds on the same commercial terms as last cycle. Don’t do that. Use the gap map as the basis for specific procurement language:
- Remediation timelines tied to attested commitments. If the vendor has attested to eliminating default credentials, ask for a named release version and target date for the products you actually run — not the product family in general.
- SBOM delivery as a contract deliverable, not a website download that may or may not stay current, so your vulnerability management tooling can ingest it on a schedule you control.
- Legacy product coverage clarity. Ask directly whether currently deployed firmware/software versions are in scope for any attested improvement, or whether reaching attested-equivalent security requires an upgrade — and if so, what that upgrade costs in engineering time and validation, not just license fees.
- Vulnerability disclosure SLAs in writing, with response and patch-availability windows specific enough that you can hold the vendor to them during your next incident.
None of this requires waiting for CISA to make attestations formally mandatory, which is the direction the policy is heading but not yet where it fully sits. The letters already exist. The contract renewal windows already exist. The gap between your documented SL-C shortfalls and what’s actually attested already exists too — it’s just sitting in a folder most teams haven’t opened since the renewal packet arrived. Open it. That’s where the actual leverage is.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
